IBIS Macromodel Task Group

Meeting date: 27 August 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                              Wei-hsing Huang
Aurora System:              * Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Dassault Systemes:            Longfei Bai
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
                              Sai Zhou
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Samsung:                      Jun-Bae Kim
Siemens EDA (Mentor):       * Arpad Muranyi
                              Randy Wolff
Signal Edge Solutions         Benjamin Dannan
Teraspeed Labs:               [Bob Ross]
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Arpad noted that the meeting scheduled for August 20th had been cancelled.

- Arpad asked whether we should cancel the meeting scheduled for September 3rd,
  the day after the US Labor Day Holiday.  The group decided to cancel.
  
- Michael noted that the Editorial Task Group will reconvene on Friday,
  September 6th, to begin work on IBIS 8.0.  He suggested Arpad's recent email
  regarding some inconsistencies in language in the specification could be
  discussed there.  He welcomed anyone interested in drafting IBIS 8.0 to join
  the Editorial Task Group meetings.

-------------
Review of ARs:

Kinger:  Send his "Add Support of Power Delivery (PD) Analysis in IBIS" to the
         ATM list.
         - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the August 13th
meeting.  Michael moved to approve the minutes.  Walter seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD220.1 update:
Arpad reported that Yifan had begun testing with the SPICE circuit he had shared
with her (see minutes from July 30, 2024), but she had not completed the case
study and was not yet ready to report on the results.

[Ramp] and Ts4file:
Michael briefly reviewed the Ts4file section (10.10) of the specification.  He
said the issue is that the ibischk parser does not modify its behavior at all
when Ts4file is used.  The parser continues to attempt to the check the [Ramp]
keyword value vs. what would be expected from the I-V and V-t tables.  He said
he had originally proposed adding language to specify the way in which the
legacy analog keyword data is measured when Ts4file is used, but at previous ATM
meetings it had been pointed out that Ts4file was supposed to replace the legacy
analog data entirely.  Michael noted that the [Ramp] keyword is required in all
[Model]s, and he noted that he had recently sent out proposed language for a
parser BUG report to address the current behavior.  The proposed BUG language
states:
  The intent of the Ts4file parameter in IBIS-AMI models is to replace all
  analog information for the buffer, including the [Ramp] keyword, I-V table
  data (i.e., [Pulldown], [Pullup], etc.) and V-t data (i.e., [Rising Waveform]
  and [Falling Waveform]).  As a result, the IBISCHK parser should not check for
  consistency between I-V and V-t and/or [Ramp] data when Ts4file is present.

The BUG suggests that the parser should instead issue a message of the form:
  "Ts4file detected; analog keywords including [Ramp], [Rising Waveform],
   [Falling Waveform], and any I-V tables are ignored"

Walter said that if you have an AMI [Model], and it uses Ts4file, then it should
not provide any legacy I-V and V-t table data.  [Ramp] is still required, but
Walter agreed that if I-V and V-t data are not provided then there's no checking
for their consistency with [Ramp].  However, if the [Model] uses Ts4file and it
also provides I-V and V-t tables, shouldn't a simulator be able to use the I-V
and V-t data in non-AMI simulations?  If the model maker provided a Ts4file for
AMI purposes, but they also performed a SPICE->IBIS and provided the legacy
analog data, why not have the parser perform the I-V and V-t vs. [Ramp] tests?
Michael agreed and said that this had been his original point of view.

Michael noted, however, that many tools use [Ramp] as fundamental indication of
bandwidth limits.  So, we have to make sure [Ramp] is consistent with what's in
in the Ts4file.  Walter asked why you can't just run a simulation with the
Ts4file driver circuit (10.10.1) into a 50 Ohm load?  He said that would give
you the information you need for the [Ramp] values.  Arpad and Michael said the
parser isn't capable of running that "simulation" to confirm the [Ramp]
information.  Arpad said that ideally [Ramp] should be checked against legacy
analog I-V and V-t data, Ts4file, and even [External Model] if they are
provided.  Fangyi said this would be nice, but the work might be beyond the
scope of the parser.  He said we should at least add language to the
specification making it clear to model makers that the dV/dt value(s) in [Ramp]
should be consistent with the Ts4file.  Walter said that a Ts4file into a 50 Ohm
load has a very simple solution, and the parser wouldn't need to run a full
"simulation."

Fangyi said Ts4file language clarifications weren't necessary, since the
specification already says it is for AMI purposes.  Ts4file is for AMI, and the
legacy analog data might be used for SPICE/transient simulations if it's
provided.  Arpad said it isn't quite that clear cut.  He said that saying
Ts4file is "specifically designed for AMI applications" is vague.  He said an
AMI simulation starts with the channel characterization portion.  The question
is, how do you do it?  Before we had Ts4file, the simulator ran a step response
simulation and took the derivative to get the impulse response (IR).  Now, if
Ts4file is provided, you can compute the IR the old way, or you could possibly
go directly from Ts4file straight to an IR.  There are two options now.  Fangyi
agreed and said that the language should be more clear on that point.

Arpad said that Ts4file was invented for AMI purposes, but why would we prevent
Ts4file from being used for normal time domain simulations?  Fangyi said that is
what the specification currently says, "...By definition, the placement of the
Ts4file information within .ami files makes the Ts4file data exclusively limited
to AMI applications."  Fangyi said we should decide whether we want Ts4file to
be used in SPICE type transient simulations, or only for AMI channel
characterization.  Michael said he thought that we should only use Ts4file for
the channel characterization portion of an AMI simulation, and it should not be
used generally for non-AMI simulations.  He said that fact that Ts4file is an
AMI parameter strongly suggests it's only for AMI.  Arpad said we should create
language that makes that suggestion, but he was not sure we want to prohibit the
use of Ts4file outside of AMI.  Fangyi said a model developer might intend that
the Ts4file only be used for AMI channel characterization, but a model user may
not know that unless the specification says something about it.  He said that
if we want to limit Ts4file to AMI channel characterization, then we may want to
require the legacy analog keywords to be provided.  Arpad said in that case we
would want to check to make sure the analog keyword data is consistent with the
Ts4file data.

Michael and Fangyi proposed changing the language to state that Ts4file is for
"analog simulation for channel characterization."  Arpad said this language
could cause confusion, as we keep referring to the "analog portions" of the
[Model] when we discuss I-V and V-t data, etc.  Michael suggested "initial
channel characterization" instead.

Fangyi and Arpad suggested that, regardless of what we decide to ask the parser
to check, we should add language making it clear to model makers that the [Ramp]
data should be consistent with Ts4file data and/or legacy I-V and V-t data if
they are provided.

Fangyi asked whether [Ramp] and [C_comp] are always required.  Fangyi and Arpad
noted that we have the same issues with [Ramp] consistency when [External Model]
is used that we do when Ts4file is used.  The group reviewed IBIS 7.2 for
language related to whether [Ramp] and [C_comp] are required.  Section 6.3.6,
External Model, specifically states that [Ramp] must still be provided.
However, C_comp is listed amongst the subparameters that may be omitted in a
[Model] specifying [External Model].  Arpad noted that on page 61, C_comp (or
C_comp_xxx subparameter(s)) are listed as required, but no mention is made of
the fact that they aren't required in the [External Model] case.  Michael said
we could add the [External Model] disclaimer to page 61.

Arpad asked why, in Section 6.3.6, page 137, the V-t waveform keywords aren't
listed amongst the keywords that can be omitted.  Michael said they're never
required.  Arpad agreed, but he said neither are the I-V table keywords, and
they are listed as keywords that can be omitted.  Michael agreed that we might
want to add the [Rising Waveform], etc., V-t keywords to page 137.

Michael noted that page 136 contains the statement about the intended use of
[Ramp] data:
  However, when used within the scope of [External Model], the [Ramp] keyword is
  intended strictly to provide EDA tools with a quick first-order estimate of
  driver switching characteristics.
Arpad suggested that we should add Ts4file in addition to [External Model].
Fangyi agreed with this addition, but he wondered why we need the "when used
within the scope of ..." at all.  Why do we limit the scope of this statement?
Removing the scope qualification statement would be the minimal change that
addresses the issue.

Michael said we still have to consider how we want the parser to handle these
issues.  He suggested that at a minimum the parser should say that if Ts4file is
present then it is dominant.  He asked whether we should consider having the
parser perform the "mini simulation" to check [Ramp] vs. Ts4file.

- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

- None.

-------------
Next meeting: 10 September 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
